An ABAC policy defines access control permissions based on the attributes of the subject, of the resource, and of the action that the subject wants to perform on the resource (e.g., read, write). A resource may be, inter alia, a portion of a personal storage quota, a business unit storage quota, an information retrieval system, a (portion of a) database, an online service, a protected webpage or a physical device.
There currently exist general-purpose AC languages that have the richness to express fine-grained conditions and conditions which depend on external data. One particular example of an AC language is the eXtensible Access Control Markup Language (XACML) which is the subject of standardization work in a Technical Committee of the Organization for the Advancement of Structured Information Standards (see http://www.oasis-open.org). A policy encoded with XACML consists of functional expressions in attribute values, and the return value (decision) of the policy is one of Permit, Deny, Not Applicable, or Indeterminate. An XACML policy can apply to many different situations, that is, different subjects, resources, actions and environments and may give different results for them. The XACML specification defines how such a request is evaluated against the policy, particularly what policy attributes are to be evaluated or, at least, which values are required to exist for a successful evaluation to result. Key characteristics of this evaluation process are that the request (the query against the policy) must describe the attempted access to a protected resource fully. In practice, it may be that the request is constructed in multiple stages by different components, so that a PEP (Policy Enforcement Point) provides only some initial attribute values and a PDP (Policy Decision Point) or other components can dynamically fetch more values from remote sources as they are needed.
XACML-based solutions typically introduce “authorization as a service” whereby a Policy Enforcement Point (PEP) within a target application/system captures access requests in real time and sends them to a Policy Decision Point (PDP) for evaluation against one or more XACML policies. In practice, however, many organizations operate systems for which there are currently no PEP components available, and whose authorization mechanisms are built around other models than ABAC.
As one example of such non-ABAC models, the Security Assertion Markup Language (SAML), which is also standardized within OASIS, provides an XML-based framework for creating and exchanging security information between online parties, such as user authentication, entitlement and attribute information, to facilitate federated security scenarios. Windows Identity Foundation (WIF), available from Microsoft Corp. of Redmond, Wash., is a platform tool having SAML support and being designed for building claims-based applications and services.
In the SAML framework, the concept of claims or authorization claims was introduced as a more flexible, granular artifact for authorization than the roles in role-based authorization security. One purpose of a claim is to assert the identity of the authenticated user and the user's access rights. While carrying the same claim, a user may experience different access rights depending on the resource solicited, values of environment variables (e.g., time of day and geographic coordinates) and any changes made by the system administrators in the various systems the user interacts with. A claim reflects an assertion about a property of an entity (whether subject or resource) whose validity can be contested and eventually verified by relying on some common source of trust. A claim may be encoded in metadata in a distributed fashion, such as by annotating, on the one hand, user profiles with the authorization claims they carry and, on the other hand, resource profiles with the claims which are to cause them to permit access. This is an example of such distributed encoding:
User1                claimA, claimB        
User2                claimA        
File1                read: claimA, claimB        write: claimA        delete: -        
Folder2 and files in Folder 2                read: claimB        write: claimB        delete: claimB        
Distributed encoding may have advantages since enforcement typically happens at resource level, whereas it may be desirable to modify permissions both in a user-oriented and a resource-oriented fashion. Considering the totality of authorization data present in a computer system at a given time, however, each nonempty claim gives rise to what may be referred to as a privilege relation associating at least one user identity, at least one resource identity and optionally environment and/or action data. The privilege relation is an abstract entity, which may not necessarily be encoded as such in the computer system but may be derived on the basis of metadata pertaining to those objects (resources), user profiles etc. in which a given claim is present. Continuing the previous example:
Privilege relation of ClaimA                carried by users: User1, User2        carried by objects: File1        effects: read or write File1        
Privilege relation of ClaimB                carried by users: User1        carried by objects: File1, Folder2        effects: read File1, read or write or delete Folder2        
Applications are typically more flexible if authorization is not tied to a fixed set of roles. Role-based authorization, as introduced above, works smoothly in an application that will always rely on a specific set of roles to authorize access and in which those roles will always carry the same meaning in terms of access rights to features and functionality. However, the meaning of roles often varies across different user groups of an application and thus require customization. That might mean evaluating roles differently depending on the user's domain, or allowing custom roles to be created to control access rights. A claims-based security model allows roles to be decoupled from the authorization mechanism, so that logical roles can be mapped to a more granular set of claims, and the application authorizes access based on those claims. If modified or new roles warrant a different set of claims to be issued, the application is not affected. Deepened information on claims-based authorization may be obtained from US 2010/299738 A1.
In computer system where the hardware, operating system and applications support claim-based or role-based authorization, it may still be desirable to define, enter and/or maintain users' access rights in ABAC policy form. In this situation, frequent conversions from ABAC policy form into claim-based or role-based form are to be expected. It has proven to be a challenging problem to perform these conversions in a computationally efficient manner.